IBIS Macromodel Task Group Meeting date: 10 October 2017 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: Michael Mirmak Keysight Technologies: Fangyi Rao Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that Bob will be at EPEPS next week (conference Monday through Wednesday, IBIS Summit Wednesday). Arpad asked if we should cancel next week's meeting. Bob noted that Radek was expected to be there too (unsure of his status because of the wild fires in CA). No one else was known to be attending. No decision was taken to cancel, but Arpad noted that we might make that decision later and inform the list via email. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Bob: Motion to approve the minutes. - Walter: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: Unused port terminations in BIRD 189: - Arpad: Should we suspend this discussion since Radek can't be here? - Walter: I don't want to neglect Radek's input, but I think we should review Bob's latest suggestions. - Bob: [sharing his Updated Unused_port_termination Rules email] - Formal documentation of rules and their key points. - Options "Open" or "Reference". - Open - unterminated. - Reference - effectively terminates with the reference impedance(s) of the port(s) from the Touchstone file, with the idea that the unused ports are actually to be removed (matrix reduction). - The second point is that the EDA tool may allow the user to override these options. - The parameter is required, Open or Reference must be declared (note: the parameter is only required if fewer ports are specified than are required for the File_TS or File_TS0). - Walter: I think you've written up the intent of what you wanted, and you captured my impression of what the two of us agree on. - One minor detail, for Open we may want to point out that tools can terminate with a high impedance for stability. This is a minor point. - My view of the difference between Radek and us: - He wanted it to be optional and default to Open. - He wanted two other options. - I think we are all in agreement about the need for this parameter, but we differ on the details (defaults, various options, etc.). - I suggest that for the next draft version of the BIRD we insert the changes as Bob as written them. This way it's in the document, but we know we are leaving it an open issue as to whether we need to adopt changes proposed by Radek. - Bob: I agree. I don't care for Radek's suggestions. They venture into user selection at that point, and it's way too complicated. - Walter: We are in agreement, and we both understand Radek should have the opportunity to review this and advance his proposals. - Randy: Would it be helpful to include one more sentence to describe the option of using an IBIS-ISS wrapper around the Touchstone file to provide terminations? I believe Radek mentioned this as the best way for the model maker to specify the per port impedances. - Bob: I think it's self-evident. - Randy: It's kind of a cookbook statement. - Bob: I don't like that suggestion because it's a very inconvenient way to allow matrix reduction. If you have an s100p, and you wrap it in a four port IBIS-ISS subcircuit, then you have to provide 96 terminations in the IBIS-ISS for the non-exposed ports. Then you'd have to do it again if you wanted another 4 pins exposed. It's the same as not having an unused_port_termination. - Okay, I'll think about adding a sentence for this. - I'll get this stuff into the next draft and then Radek can continue the discussion. C_comp improvements: - Walter: I think where this is going to end up is that for an I/O, because of the way resistors turn on and off, there are really going to be two models, one for driving mode and one for receiving. - I have a question for Randy. Is there a case when the clamping diodes are different depending on whether the device is driving or receiving? - Randy: I have seen some drivers where the driver circuitry is separated from the pad by a transistor that you could use to switch out the driver, while the receiver is always there on the pad. That's some older technology designed to reduce the capacitance seen in Input mode. - Walter: So are the ESD clamping diodes on the Rx side so they don't get shut off? - Randy: Yes, that's where they would be. - Walter: Thanks, you've answered my question. I thought perhaps the driver might have its own separate ESD devices. - Randy: One thought there is that a driver transistor acts like a diode when it's disabled. - Walter: But then when it's disabled you're in receiver mode, and you have a big resistor in between it and the receiver, right? - Randy: Not necessarily, you could have an ESD specific diode that might be on your pad, but also have some diode-type current that is from the disabled driver structure. - Usually if the driver's disabled and you sweep an I/V curve you see a combination of these two. - In practice, ESD devices often aren't modeled all that well as diodes. - We sometimes have to replace the ESD model with a different diode or transistor model to approximate the effects we see in measurements that aren't replicated in the plain ESD models themselves. - Bob: In general, for the model itself, you would use the same structure whether it's driving or receiving. - If there are fundamental I/V changes between driving mode and receiving mode at the clamp level, IBIS can handle that with Submodels. These are often used for on-die termination, but they could also be used to model clamp variations. - My understanding is that part of the C_comp proposal also includes something that should not be modeled with clamp currents, though it could be, that is a series resistance included when a buffer is a receiver. It's a different phenomenon than would normally be modeled with clamp currents. - Randy: I'm not sure how many people would want to include that in a C_comp model, but a series resistance added as a sort of RC filter for the input is a structure that exists for many input buffers. - It is desirable for me to model that as part of a C_comp, but we haven't heard many other people talk about whether they would use it. - Walter: In that case, the clamping diode is on which side of that resistor? - Randy: Typically it's still on the pad side. - Walter: And we are turning that resistor on or off, or the R value changes when driving or receiving? - Randy: Think of it as the input buffer and the resistor are always there, in driving or receiving mode. It's just interesting the look at the signal passing through that resistor in input mode. - Arpad: The driver doesn't drive through that resistor. - Randy: Right, it would be a strange situation and we don't model that effect. - Bob: You don't worry about filtering the driver, but the receiver gets a filtered response. - Randy: Right. - Bob: If that resistor were part of a clamp circuitry you might have a double counting effect if it showed up in the POWER_Clamp and GND_Clamp. That could get tricky. In the new version we'd have a series RC instead. - Since we're dealing with a receiver, we don't have issues with the K-table extraction for a driver. - Randy: Clamping currents, power and ground, are much less useful than they used to be. With terminated buses you rarely have overshoot beyond the voltage rails anymore. BIRD 189: - Arpad: We had a private email exchange amongst several of us related to Interconnect modeling and how to group the various keywords and how to eliminate the extra selections that might be need within Interconnect Model Sets. - Walter: I was suggesting that a Pin can't be in two different Models as a victim. - If you're doing a simulation and want to simulate certain pins as victims, then the way we do it now is the user puts the package model in and has to hook it up properly. - We want to automate that. You want to find the model that has all the user selected pins as victims. - This is the case for Randy when he does an S-parameter for the DDR bus. He generates a Touchstone file for all the pins on that bus. The EDA tool could then look for the Model that has all the required pins as victims. - Arpad: That would work if we assume that any lines designated as "aggressor only" could only be used for crosstalk simulations. Currently the BIRD doesn't prohibit doing a single-channel simulation with an aggressor. As soon as we allow pins to appear multiple times as aggressors, as you describe, we might still need a selection in that case. - Walter: As a practical matter, if someone is going to do something like swathing: - The model maker has a bunch of s6p crosstalk files (for a pin with two adjacent aggressors). - One s6p is for one as a victim, another is for a different one as the victim. There are going to be multiple models with a given pin as an aggressor. Would you ever have a case where a pin is an aggressor in two different models but never a victim? If the model maker has gone through the effort to make this configuration, why would a pin never be modeled as a victim? - Arpad: That's not the case I was concerned about. - I'm worried if there are multiple models with the same pin as an aggressor, and you only want to simulate that one pin. - Walter: I think that would be poor style by the model maker to have a pin that is an aggressor in multiple models, but is never a victim in a model. - In that case, the user might have to make a choice, but the model maker can fix that issue. - Walter: If we follow my rule, any victim should have a model with its thru- channel and all its aggressors. - Bob: This is an Interconnect Model, essentially replacing packages. - Many models will be issued without the optional "aggressor" tags. - We know no [Interconnect Model] can describe the same pin twice (the exception being the same pin can appear twice if you have the Set broken up so that one Model handles the buffer to pad path, and another Model handles the pad to pin path separately (so you need both to get the complete path for that pin)). - Within a Group, which makes reference to Sets, my proposed rule is that a Pin's description should only appear once. I don't care about aggressors or victims yet, I just care about documenting paths. - The EDA tool can simulate which ones are aggressors and which ones are victims and get coupled in contributions from wherever it wants. - A fundamental requirement is that there is no selection necessary within a Group. - Walter: If you want a rule like that, you have to define it for a programmer so they can confirm they can implement such a rule. - Could you create a document that explains your rule and how the programmer can implement it? - Then we can debate whether we want to implement it. - Bob: I will do that. I think my rule is simpler than the aggressor/victim related rule. - Arpad: I have a swathing question. - Let's assume we have no issue with selecting the right Model Set. - Say I'm modeling a diff pin pair with a neighbor aggressor on each side. - I have an s8p. My main point is this has two victims. If you swath this, how do you "slide it over"? - Walter: I don't really swath it. - Say I have 1 and 2 are the first diff pair, 3 and 4 the second, 5 and 6 the third. - Let's say in one model 3 and 4 are the victims, and 1 and 2 and 5 and 6 are the aggressors. We have an s12p where the 4 "outside" pins are the aggressors. - There is another s12p for 3-4, 5-6, and 7-8, with 5 and 6 as the victims. - I would create a second model (perhaps instantiating the same s12p) for the 3-4, 5-6, 7-8 case. - Arpad: Okay, so it does shift (or slide) by the number of victims in the middle. I was worried about only sliding over by one and having the same pin appear as a victim in more than one Model. - Bob: We are being sloppy with nomenclature. - We are talking about "Models" as the whole thing. - More precisely we should be talking about Groups and Sets. - We may be in agreement, but just not using the same language. - Walter: All I'm saying is ignore that no-repeats rule for pins labeled as aggressors. - Bob: You don't want the same pin path documented doubly in the same Group. - If you want it repeated as an aggressor, put in a different Group. - Arpad: Bob, you took the AR to write up your rules so we can study them. - Walter: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Bob Ross to send out his proposed no-pin-duplication rules for BIRD189. ------------- Next meeting: 17 October 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives